home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re(2) Converting MacApp Exam.1 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.8 KB  |  [TEXT/ttxt]
  1. Subject:     Re(2): Converting MacApp Example to ODF
  2. Sent:        5/31/96 10:00 AM
  3. Received:    5/31/96 9:09 AM
  4. From:        John Major, jmajor@dayna.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. 'lo, folks -
  9.  
  10. I have a keen interest in converting/moving code back and forth between MacApp
  11. and ODF, and spent some time at WWDC exploring this issue. I imagine that it
  12. is of interest to a number of other folks as well, given:
  13.  
  14. - The large MA code base that could turn into OD part editors
  15.  
  16. - Apple's interest (and the "World at Large"!) in seeing many part editors
  17. appear soon
  18.  
  19. - The MA code base's interest in going cross-platform
  20.  
  21. Let's assume that the MacApp team's vow at WWDC ("MacApp Reanimated") to bring
  22. OD container support to MA will pay off ASAP - instant Internet apps! But what
  23. I'm talking about is making MA code into a part.
  24.  
  25. A good sign here is that the ODF team and the MacApp team are now "under the
  26. same roof", and appear to be cooperating effectively (some might view this as
  27. very "Un-Apple" behavior, but there's a fresh wind blowing in Cupertino!).
  28. It's hard, I imagine, as there are always internal rivalries and resource
  29. battles about stuff like that, but here's hoping that they are striking the
  30. right balance between bringing MA forward (and all the code out there that it
  31. represents), and putting the muscle behind ODF that it requires to be a
  32. success. I imagine that the key thing is that the *rest* of Apple needs to
  33. have a clear understanding of how important these frameworks are to the
  34. success of their OS technologies. This is something that Microsoft appears to
  35. have understood from the get-go with MFC, and already making lots of money in
  36. the Dev Tools business, had no problem putting all the oomph behind MFC that
  37. it required. But now Apple, whatever the past history, is more and more in the
  38. OS business, and needs to give these frameworks the resources they need to
  39. support the OS.
  40.  
  41. On this note, then, I have to say that conspicuously absent from the picture
  42. so far is a tool to move MA views to ODF, or better yet, to use them
  43. simultaneously with both frameworks (given the excellent tools on the MA
  44. side). There was even a note in the early Vger docs to the tune of "I'm going
  45. to drop MA support, because I don't know anyone who's interested in this" -
  46. ARGH! I imagine that I have lots of company, so speak up, folks... Spec Bowers
  47. and AppMaker has the ability to generate ODF from his native resource format,
  48. but he hasn't had time yet to do the fairly straightforward work of being able
  49. to read in the MA views - so once again, speak up, MacAppers!
  50.  
  51. I'd be interested if any MA folks have a sense of how much of their app code
  52. falls into the following categories:
  53.  
  54. - Completely or nearly independent of framework code - easy to share with an
  55. OD part
  56.  
  57. - Completely or nearly restricted to isolated MA code modules - I'm thinking,
  58. say, of complex dialog management code, with behaviors, dependencies, and the
  59. like. It sounds like some of the lowest level stuff is migrating to this state
  60. - something called "ODFLib" was mentioned at WWDC. 
  61.  
  62. Could more chunks of MA be rewritten so that certain subsets of classes could
  63. be used *either* in MA or ODF? Now *that* would be code reuse! Not only would
  64. the Frameworks folks get reuse, but anyone who followed guidelines on the use
  65. of those class subsets would get reuse. I'm assuming that there are folks like
  66. me that want to migrate *pieces* of their app to part editordom as quickly as
  67. possible, but still leave the monolithic app out there for some time to come.
  68.  
  69. Well, I've gone on too long - I'll be interested to hear what others have to
  70. say.
  71.  
  72. John Major
  73. Director, Software Development
  74. AirGo Communications, Inc., 
  75. Sorenson Research Park
  76. 849 West Levoy Drive
  77. Salt Lake City, UT 84123-2544
  78. USA
  79. jmajor@dayna.com
  80. Tel: 801/269-7346
  81. Fax: 801/269-7363 
  82.